Data processing system

ABSTRACT

A method of performing a cooperative data processing, said method comprising performing a plurality of processes in each of a plurality of control modules capable of communicating with each other to perform the cooperative data processing, the plurality of processes includes a required application process of the cooperative data processing.

This application is a Continuation application of U.S. patentapplication Ser. No. 14/452,344, filed on Aug. 5, 2014, now U.S. Pat.No. (tbd).

CROSS-REFERENCE TO RELATED APPLICATIONS

The disclosure of Japanese Patent Application No. 2013-166536 filed onAug. 9, 2013 including the specification, drawings, and abstract isincorporated herein by reference in its entirety.

BACKGROUND

The present invention relates to a data processing system that makes itpossible to perform a comprehensive evaluation of cooperative dataprocessing performed by a plurality of control modules coupled through acommunication path. More specifically, the present invention relates toan effective technology applicable, for instance, to an in-vehicleelectronic control system in which a plurality of electronic controlunits (ECUs) is coupled to an in-vehicle network.

Electronic devices are increasingly used, for instance, in automobilesto increase the total number of control modules. This results in anincrease in the number of man-hours required for developing an embeddedsystem. Hence, a software development process is now being reviewed. Aprocess of verifying an actual embedded system that is performed duringa currently employed embedded system development process is mainly basedon simulation. Systems proposed in Japanese Unexamined PatentPublications No. 2010-204934, No. Hei 09 (1997)-218800, and No.2012-190197 are configured to improve the above situation.

The systems proposed in Japanese Unexamined Patent Publications No.2010-204934 and No. Hei 09 (1997)-218800 are configured to analyzesoftware for a processor having a data bus and an address bus. Thesystems insert a tag statement in an arbitrary place in the software inorder to output tag information to a predetermined address within anaddress space. Next, the systems couple a debugging device to anexternal output bus of the processor in order to monitor the bus accessof the processor. When the software is executed to output the taginformation, the debugging device identifies the tag information inaccordance with information derived from bus monitoring, acquires thetag information, and records the tag information and time. The recordedtag information and time are transferred to a calculation section andanalytically processed to analyze the software.

The system proposed in Japanese Unexamined Patent Publication No.2012-190197 is configured to analyze software that runs in a pluralityof processors. The system includes an image processing device, which isto be observed, and an external device, which provides log analysis. Theimage processing device includes one main CPU and one or more sub-CPUs.The main CPU issues a command to the sub-CPUs and records the time ofcommand issuance. The sub-CPUs record the time of command execution. Theexternal device collects the logs of the main CPU and sub-CPUs, andanalyzes the operating status of the main CPU and sub-CPUs in accordancewith the time of command issuance and the time of command execution.

SUMMARY

The inventors of the present invention make a new proposal on adevelopment process from the viewpoint of hardware. In a situation wheresoftware is evaluated with an actual product based on related art, it isfound that the number of CPUs simultaneously available for analysis islimited and that the configuration of a network is also limited.

For example, a situation where a plurality of modules is coupled is notassumed in Japanese Unexamined Patent Publications No. 2010-204934 andNo. Hei 09 (1997)-218800. Even if the modules are coupled, the number ofthem is limited due to the physical use of ports of the debuggingdevice. Even if there is no problem with the number of ports, the lengthof wiring to the debugging device increases with an increase in thedistance between the modules. This makes it difficult to couple themodules.

The system proposed in Japanese Unexamined Patent Publication No.2012-190197 acquires time while regarding the time of command issuancefrom the main CPU as a start point. Therefore, the system is onlyapplicable to a star configuration in which the sub-CPUs are coupled tothe main CPU, and not applicable to a daisy-chain configuration in whicha sub-sub-CPU is coupled to a sub-CPU. If the main CPU and the sub-CPUsuse different clock oscillators, timer value consistency is impaired dueto a frequency error. Hence, the sub-CPUs cannot be arranged physicallyapart from the main CPU. In addition, a method of correcting such timervalue inconsistency is not described in Japanese Unexamined PatentPublication No. 2012-190197.

The above and other problems to be addressed and novel features of thepresent invention will become apparent from the following description ofthe present invention and from the accompanying drawings.

The following is a brief description of a representative aspect of thepresent invention disclosed in this document.

According to the representative aspect of the present invention, thereis provided a data processing system including a plurality of controlmodules. Each control module includes a timer that counts time common tothe entire data processing system. A time synchronization process isemployed so that time information derived from the timer in a low-levelcontrol module is synchronized with time information derived from thetimer in a high-level control module. A log acquisition function isincorporated so that when, for instance, a log is acquired during anapplication process, a timestamp based on timer time is added to theacquired log. When logs output from the control modules are collectedand merged, software running in the entire system can be analyzed.

The following is a brief description of an advantageous effectachievable by the representative aspect of the present inventiondisclosed in this document.

Even when an employed system is configured so that a plurality ofcontrol modules is dispersively installed at remote places, software inthe entire system can be analyzed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a basic configuration of a dataprocessing system;

FIG. 2 is a diagram illustrating an evaluation procedure for softwareanalysis;

FIG. 3 is a block diagram illustrating the configuration of a module;

FIG. 4 is a block diagram illustrating the configuration of an SOC;

FIG. 5 is a block diagram illustrating the configuration of an actualproduct system according to a first embodiment of the present invention;

FIG. 6 is a software state diagram illustrating a first module;

FIG. 7 is a software state diagram illustrating a second module;

FIG. 8 is a software state diagram illustrating a third module;

FIG. 9 is a flowchart illustrating a procedure for actual productevaluation;

FIG. 10 is an operation timing diagram illustrating a communicationdelay measurement during a time synchronization process;

FIG. 11 is an operation timing diagram illustrating a clock errorcorrection sequence for time processing;

FIG. 12 is a diagram illustrating the time synchronization processrelationship between the modules;

FIG. 13 is a diagram illustrating the configuration of a tag table;

FIG. 14 is a diagram illustrating a process of merging unit logs;

FIG. 15 is a diagram illustrating a system log;

FIG. 16 is a sequence diagram illustrating the system log according tothe first embodiment;

FIG. 17 is a system configuration diagram illustrating a systemevaluation environment according to a second embodiment of the presentinvention;

FIG. 18 is a sequence diagram illustrating an operation performed togenerate the system log according the second embodiment;

FIG. 19 is a block diagram illustrating the overall configuration of athird embodiment of the present invention;

FIG. 20 is a timing diagram illustrating the relationship between anapplication process and a clock error correction process that areperformed in the second module; and

FIG. 21 is a system configuration diagram illustrating an applicationexample in which the present invention is applied to a system in which alarge number of modules are configured to form a network within, forinstance, an automobile.

DETAILED DESCRIPTION 1. Overview of Embodiments

First of all, embodiments of the present invention disclosed in thisdocument will be summarized. The parenthesized reference numerals in theaccompanying drawings referred to in the overview of the embodimentsmerely illustrate what is contained in the concept of elements to whichthe reference numerals are affixed.

[1] <Timer-Based Time Synchronization Process Between Control Modules>

A data processing system (201) includes a plurality of control modules(500-1, 500-2, 500-3) capable of communicating with each other. Thecontrol modules in the data processing system each include communicationinterfaces (405, 407) and a timer (404), and perform a requiredapplication process, a unit log generation process, and a timesynchronization process in accordance with a program executed by thecontrol modules. The time synchronization process is performed by thetimer for time synchronization purposes. At a test point designated by aprogram executed in the unit log generation process, the unit loggeneration process generates timestamps in accordance with loginformation and with time information derived from the timer, andaccumulates the timestamps together with attribute information about thetest point to generate a unit log. The time synchronization processsynchronizes the time information derived from the timer in a low-levelcontrol module with the time information derived from the timer in ahigh-level control module.

Even if the control modules are dispersively installed at remote places,the above-described process ensures that times indicated by timestampson unit logs generated by the control modules can be synchronized on thesame time axis. Therefore, when the unit logs generated by theindividual control modules are merged by using each timestamp as anindex, a system log of the entire data processing system can be obtainedwith ease.

[2] <Correction Made in Accordance with Timer Time Difference BetweenHigh- and Low-Level Control Modules>

Referring to section [1], in the time synchronization process, thelow-level control module receives information (T1, T5) about the timertime of the high-level control module from the high-level control moduleand corrects its local timer time in accordance with the receivedinformation about the time and with the information about its localtimer time (T2, T6) and other information (T3, T4, T7, T8) prevailingwhen the information about the time is received.

The above-described process permits the timer time of the low-levelcontrol module to be synchronized with the timer time of the high-levelcontrol module. Therefore, the number of control modules subjected totime synchronization and the form of a network are not theoreticallylimited.

[3] <Correcting Timer Time by Rewriting Timer Time>

Referring to section [2], the process of correcting the local timer timeis a process of rewriting the local timer time.

The above-described process ensures that the time derived from the timercan be directly used as a timestamp as far as a timer error iscorrected.

[4] <Correcting Timer Time by Correcting Time Information Derived fromTimer>

Referring to section [2], the process of correcting the local timer timeis a process of correcting time information derived from the local timerat the time of timestamp generation.

The above-described process eliminates the necessity of rewriting orpresetting the timer time. However, the time derived from the timerneeds to be corrected before being used as a timestamp.

[5] <Acquiring Communication Delay to Compute Timer Time Error>

Referring to section [2], a communication delay (Tdelay) in acommunication from the high-level control module to the low-levelcontrol module is acquired, then a timer time error (Tdiff, Tcd) iscomputed by subtracting the communication delay from the differencebetween actual transmission time and reception time, and the computedtimer time error is used to correct the timer time.

The above makes it possible to correct the timer time with ease inconsideration of a communication delay.

[6] <External Interfaces>

Referring to section [1], external interface circuits (405, 407)exercise control to acquire time information from the local timer uponreceipt of a first command (Sync), output a second command (Followup)together with timer time information prevailing at the time of theoutput of the first command, exercise control to acquire the local timertime information at the time of a third command (DelayReq) output, andoutput a fourth command (DelayResp) together with the local timer timeinformation prevailing upon receipt of the third command.

The above makes it possible to acquire the timer time used for timertime correction from an associated timer in accordance with controlexercised by the external interface circuits at the time ofpredetermined command transmission/reception.

[7] <Acquiring Communication Delay to Compute Timer Time Error>

Referring to section [6], the low-level control module acquires firsttime information (T2) from the local timer upon receipt of the firstcommand from the high-level control module, acquires second timeinformation (T1) about a high-level timer that prevails when thehigh-level control module outputs the first command together with thesecond command, acquires third time information (T3) about the localtimer when the third command is output to the high-level control module,acquires fourth time information (T4) about the high-level timer thatprevails upon receipt of the third command, the third command beingoutput together with the fourth command by the high-level control moduleupon receipt of the third command, computes time that is half the sum ofthe difference between the fourth time information and the first timeinformation and the difference between the third time information andthe second time information, acquires the computed time as thecommunication delay in the communication from the high-level controlmodule to the low-level control module, computes the timer time error bysubtracting the communication delay from the difference between theactual transmission time and reception time, and corrects the timer timeby using the computed timer time error.

The above makes it easy for the low-level control module to synchronizethe local timer time with the timer time of the high-level controlmodule.

[8] <External Interface's Synchronization Engine for AcquiringInformation about Command Transmission/Reception and Time>

Referring to section [7], the external interface circuits each include asynchronization control circuit that acquires first time informationfrom the local timer upon receipt of the first command, acquires secondtime information supplied together with the second command, acquiresthird time information about the local timer when the third command isoutput, and acquires fourth time information supplied together with thefourth command.

The above makes it possible to acquire the first to fourth timeinformation without placing the entire burden on a central processingunit. However, it is unavoidable to employ a method of acquiring thefirst to fourth time information by using some or all of interrupt andother control functions of the central processing unit.

[9] <Central Processing Unit's Computation of Communication Delay andTime Error>

Referring to section [8], the central processing unit computes thecommunication delay and the time error by using the first to fourth timeinformation acquired by the external interface circuits.

The above eliminates the necessity of preparing a special computationcircuit for computing the communication delay and the time error.

[10] <Communication Delay Measurement Before Application ProcessInitiation>

Referring to section [9], the central processing unit measures thecommunication delay before the start of an application process (S401)and controls a process (S400) of initially correcting the timer time byusing the measured communication delay.

To provide an adequate degree of freedom of network configuration, it ispreferred that the control modules use different clock oscillators fortimer clock generation. When this is taken into consideration, it isobvious that the efficiency of subsequent individual log generation canbe increased by synchronizing initially asynchronous timer times beforethe start of the application process.

[11] <Making Clock Error Correction with Communication Delay inAccordance with Timer Interrupts>

Referring to section [10], after the initial timer time correction, thecentral processing unit controls a process of correcting timer time withthe measured communication delay in accordance with a timer interrupt(S602-2) generated at predetermined intervals.

When the control modules use different clock oscillators for timer clockgeneration, it is preferred that all clocks used for timer's countingoperation oscillate at the same frequency. In reality, however, eachoscillation frequency has an error. Therefore, the above-describedcontrol scheme makes it possible to prevent a non-negligible error bysuccessively correcting a state where timer times are graduallyunsynchronized.

[12] <Attribute Information>

Referring to section [1], the attribute information about the test pointincludes first identification information allocated to a control module,second identification information indicative of the location of the testpoint within a program executed by the control module, and thirdidentification information indicative of a process performed at the testpoint.

The above makes it possible to readily identify information about a unitlog acquired for each control module on an individual test point basis.

[13] <Log Analysis Circuit; Collecting Unit Logs to Merge them by Usinga Test Point as an Index>

Referring to section [1], the data processing system further includes alog analysis circuit. The log analysis circuit (301) collects unit logsgenerated for the control modules, consolidates the unit logs by mergingtest point attribute information, log information, and timestamps byusing timestamps included in the collected unit logs as an index, andgenerates a system log.

The above makes it possible to readily generate the system log from theunit logs and enhance the software analysis efficiency of the entiredata processing system.

[14] <Control Modules Configured as in-Vehicle ECUs>

Referring to section [1], the control modules are configured asin-vehicle ECUs coupled to an in-vehicle network.

The above configuration not only permits the evaluation of software forall the in-vehicle networks (802, 803, 804) for the in-vehicle ECUs at adevelopment stage, but also facilitates the evaluation of failure in aparticular actual product. Hence, the reliability of an in-vehicle ECUsystem can be enhanced.

[15] <Control Modules Configured as an Actual Product System andEmulators>

The control modules are configured as an actual product (605), which isto be emulated, or as emulators (604, 606), which emulate the actualproduct.

The above configuration not only makes it possible to evaluate theactual product with the emulators, but also permits timing evaluationwith the system log. More specifically, emulation information derivedfrom the emulators can be compared against an expected value forevaluation purposes. Further, a system model descriptive of a scenarioof emulation operations of the actual product and emulators can becompared against the system log for timing evaluation or other purposes.

[16] <Timer-Based Time Synchronization Between Control Modules>

The data processing system (201) is a system in which the controlmodules (500-1, 500-2, 500-3) operate while communicating with eachother. The control modules each include the timer (404) that counts timecommon to the entire data processing system. The time synchronizationprocess (S400, S405) is performed between the control modules so thatthe time information derived from the timer in a low-level controlmodule is synchronized with the time information derived from the timerin a high-level control module.

Consequently, even if the control modules are dispersively installed atremote places, the time synchronization process performed between thecontrol modules ensures that the times indicated by the timestamps onthe unit logs generated by the control modules can be synchronized onthe same time axis.

[17] <Log Acquisition Process>

Referring to section [16], the control modules perform a log acquisitionprocess (S401) during the application process to acquire a log and add atimestamp based on timer time to the acquired log.

Consequently, timestamps indicative of times synchronized on the sametime axis within the entire system can be added to the logs acquired bythe individual control modules.

[18] <System Log Generation Process>

Referring to section 17, the data processing system further includes alog analysis circuit (301) that collects logs acquired by a logacquisition function of the individual control modules, mergesinformation about the collected logs in accordance with timestamps, andgenerates a system log of software running in the entire data processingsystem.

Consequently, the software running in the entire data processing systemcan be readily evaluated by using the system log.

2. Details of Embodiments

Embodiments of the present invention will now be described in furtherdetail.

First Embodiment

FIG. 1 illustrates a basic configuration of the data processing system.A later-described actual product 201 is an example of the dataprocessing system. The data processing system includes a plurality ofdata processing units or control units or other control modules(hereinafter may be simply referred to as the modules). Particularly,attention is focused on the modules that are coupled and provided withseries signal paths. Here, more specifically, attention is focused onthree modules 500-1, 500-2, 500-3 having series paths 502, 503. Althoughthe modules 500-1, 500-2, 500-3 are provided with the series paths 502,503, the modules 500-1, 500-2, 500-3 may be additionally provided withsome other coupling paths.

The modules 500-1, 500-2, 500-3 each include a central processing unit(CPU) 401-1, 401-2, 401-3, a synchronization timer 404-1, 404-2, 404-3,and communication interfaces 405-1, 407-1, 405-2, 407-2, 405-3, 407-3.The modules 500-1, 500-2, 500-3 perform a required application processand a unit log generation process in accordance with a program that isexecuted by the modules 500-1, 500-2, 500-3. Further, the modules 500-1,500-2, 500-3 perform a time synchronization process to synchronize timertimes, namely, measured values.

The unit log generation process is a process in which the CPU 401-1,401-2, 401-3 in each module 500-1, 500-2, 500-3 generates unit logs onan individual module basis. More specifically, the unit log generationprocess is performed to generate log information and a timestamp at atest point designated by a program executed by the CPU in accordancewith time derived from the synchronization timer 404-1, 404-2, 404-3,and accumulate the generated log information and timestamp together withattribute information about the test point.

The time synchronization process is performed to synchronize timeinformation carried by the timestamps generated by the synchronizationtimers 404-1, 404-2, 404-3. In other words, the time synchronizationprocess is performed to assure that the time information derived fromthe synchronization timers 404-1, 404-2, 404-3 is expressed on the sametime axis. In the time synchronization process, for example, the module500-2 receives information about the time of the synchronization timer404-1 from the module 500-1, which is a high-level module from theviewpoint of time management, and corrects the time of the localsynchronization timer 404-2 in accordance, for instance, with thereceived information about the time and with the information about thetime of the local synchronization timer 404-2 that prevails when theinformation about the time of the synchronization timer 404-1 isreceived. The times of the synchronization timers 404-1, 404-2, 404-3may be corrected by correcting time information derived from the localsynchronization timer 404-1, 404-2, 404-3 or by correcting the countingoperation of the local synchronization timer 404-1, 404-2, 404-3 with,for example, a preset count value. A process of correcting the times ofthe synchronization timers 404-1, 404-2, 404-3 may be performed, forinstance, by the CPU as a part of a power-on reset process or at thebeginning of a predetermined processing routine. If a non-negligibleerror occurs over time in the synchronization of time information aftera correction process in a situation where the clock signal frequenciesof the synchronization timers 404-1, 404-2, 404-3 in the modules 500-1,500-2, 500-3 are not exactly the same, the correction process may beperformed again after an appropriate interval.

When the data processing system, which is handled as an actual product,is operated to let the modules 500-1, 500-2, 500-3 generate theirrespective unit logs, and the resulting pieces of log information aboutthe generated unit logs of the modules 500-1, 500-2, 500-3 are merged byusing a timestamp as an index, data processing performed by using themodules of the actual product can be evaluated with ease.

The data processing system and a processing procedure for evaluating thedata processing system will now be described in detail.

FIG. 2 illustrates an overall procedure of evaluating the dataprocessing system.

The following description deals with a case where an actual productsystem 201 configured as the data processing system formed of threeunits of the module 500 depicted in FIG. 3 is subjected to operationanalysis. The actual product system. 201 corresponds to the dataprocessing system depicted in FIG. 1. As illustrated in FIG. 3, themodule 500 includes an SOC (a system on a chip formed of a singlesemiconductor chip) 400, a secondary storage medium 501, and otherdevices 510.

As depicted in FIG. 4, the SOC 400 includes a synchronization timer 404for achieving time synchronization with an external module,communication interfaces (IF_A 405, IF_B 407) having a built-insynchronization engine (synchronization engine A 406, synchronizationengine B 408) for providing assistance to the time synchronizationprocess, an interface IF_C 409 for communicating with the secondarystorage medium, and a CPU 401. Synchronization engine A 406 andsynchronization engine B 408 are not specifically limited, but arecapable of acquiring and retaining the time information about thesynchronization timer in the local module when transmitting or receivinga later-described predetermined command. The retained time informationis used in the time synchronization process. The use of the retainedtime information will be described in detail later.

FIG. 5 illustrates how the individual modules are coupled within theactual product system 201. As described with reference to FIG. 1, thethree modules 500-1, 500-2, 500-3 are coupled. The first module 500-1 iscoupled to the second module 500-2 through a communication path 502. Thesecond module 500-2 is coupled to the third module 500-3 through acommunication path 503. The three modules 500-1, 500-2, 500-3 aredaisy-chained to form a system.

The processing procedure for evaluation can be divided into softwareimplementation 100, actual product operation 200, and log analysis 300.The procedure for software implementation 100 is performed to formulatethe specifications for software and implement the software. Theprocedure for actual product operation 200 is performed to actuallyoperate the actual product system 201 and acquire a unit log set 202 ofthe software. The procedure for log analysis 300 is performed to analyzethe unit log set 202 and generate a system log 303 and a verificationresult 304. The unit log set 202 is a set of the aforementioned unitlogs.

The procedure for software implementation 100 is performed to create aunit source set 104 and a tag table 105 in accordance with systemspecifications 101. The unit source set 104 is a collection of sourcecodes implemented in each module 500. The system specifications 101include application specifications 102, which define functions(applications) to be implemented by the actual product system 201, andtest specifications 103, which define test items. The unit source set104 generated in accordance with the system specifications 101 includesthe functions of the applications and the source codes for softwareanalysis.

FIGS. 6, 7, and 8 are state diagrams illustrating the applicationspecifications 102 for the individual modules. The state diagramdepicted in FIG. 6 is implemented in the first module 500-1. The statediagram depicted in FIG. 7 is implemented in the second module 500-2.The state diagram depicted in FIG. 8 is implemented in the third module500-3. Although not specifically limited, the application specifications102 described here define an operation in which a command transmittedfrom the first module 500-1 to the second module 500-2 is forwarded tothe third module 500-3 through the second module 500-2 to let the thirdmodule 500-3 choose in accordance with an event generated upon receiptof the command whether or not to return a response to the first module500-1. Referring, for instance, to FIG. 6, when an IF_B transmissionrequest is generated (S103) while the CPU 401-1 of the first module500-1 is in an idle state S100, an interface command of the interfaceIF_B is given to the interface IF_B 407-1 to complete the IF_Btransmission by the interface IF_B 407-1 (S104). Accordingly, when anIF_B reception request (S209) is generated, the second module 500-2depicted in FIG. 7 uses the interface IF_B 407-2 to receive theinterface command of the interface IF_B (S203) and completes the commandreception by the interface IF_B (S210). Further, when an IF_A relaytransmission request is generated (S207) in the second module 500-2, theinterface IF_A 405-2 performs a command transmission process (S202) tocomplete the transmission of the command to the module 500-3 (S208).Subsequently, when an IF_A reception request (S310) is generated, thethird module 500-3 depicted in FIG. 8 uses the interface IF_A 405-2 toperform an IF_A command reception process (S301) to complete thereception of the relayed command (S305). This causes the third module500-3 to switch into a command wait state (S302). Subsequently, when,for instance, event A is generated (S307), an event process is performed(S303), and then a transmission request for notifying the termination ofthe event process is generated (S308). Accordingly, an IF_A interfacecommand is given to the interface IF_A 405-3 to complete thetransmission of the event termination notification by the interface IF_A403-1 (S309). Subsequently, the second module 500-2 performs processesS211, S204, and S212, uses the interface IF_A 405-2 to receive an eventprocess termination notification, and performs processes S205, S201, andS206 to let the interface IF_B 407-2 transmit the event processtermination notification. Finally, the first module 500-1 performsprocesses S105, S102, and S106 as indicated in FIG. 6 to receive theevent process termination notification.

A unit source 106 includes a time synchronization source 107, a taginsertion application source 108, and a tag management source 109. Thetime synchronization source 107 makes adjustments so as to equalize thevalues of the synchronization timers (404-1, 404-2, 404-3) of themodules (500-1, 500-2, 500-3) included in the actual product system 201.The tag insertion application source 108 is obtained when a tagstatement is inserted into a source code for an application process. Thetag statement is inserted into the test point defined by the testspecifications 103. When the program reaches the tag statement, the tagstatement starts a tag management process to notify tag information.

The tag information includes a net ID, a tag number, and a tag value.The net ID is a unique identification number assigned to each module. Inthe present embodiment, a net ID of 1 is statically assigned to thefirst module 500-1, a net ID of 2 is statically assigned to the secondmodule 500-2, and a net ID of 3 is statically assigned to the thirdmodule 500-3. Although the net IDs are statically assigned in thepresent embodiment, they may be dynamically assigned depending on theconditions. The tag number and the tag value are pieces of informationused for test point identification. Thus, the tag information includingthe net ID, the tag number, and the tag value is defined as an exampleof attribute information about the test point. In the presentembodiment, the tag statement is inserted into sources corresponding toS103 and S106 in FIG. 6, S205, S207, S210, and S212 in FIG. 7, and S305,S306, S307, and S308 in FIG. 8.

The tag management source 109 is a source code in which the tagmanagement process is implemented. The tag management source 109generates a unit log that is obtained by adding the time of thesynchronization timer 404 to the tag information, and performs a taginformation management process, for example, to buffer information intoa RAM 402, which is a primary storage, and save a unit log into a ROM403, which is a secondary storage, and/or a secondary storage medium501. The secondary storage medium 501 is a nonvolatile memory includinga dynamic random access memory, a static random access memory, or amemory card.

The tag table 105 is a table that manages the tag information. Asdepicted in FIG. 13, the tag table 105 shows the relationship betweentag numbers, tag values, and converted values. The tag table 105 isreferenced to convert the tag information derived from actual productevaluation 203 into an arbitrary form. The converted values may bechanged in accordance with an employed software analysis method. In thepresent embodiment, the converted values are in text form.

The unit source set 104 is compiled 111 to obtain an executable code set110. The executable code set 110 is a set of binary codes executable bythe CPU 401 in each module 500. The actual product system 201 is builtby writing the executable code set 110 into the ROM 403.

In the actual product operation 200, the unit log set 202 is obtained bysubjecting the actual product system 201 to actual product evaluation203.

In the above instance, the modules are coupled by the interfaces (IF_A405, IF_B 407) having a synchronization engine. The actual productsystem 201 is capable of synchronizing the times of the synchronizationtimers 404-1, 404-2, 404-3 by performing the power-on reset process orby performing the time synchronization process after the start of actualproduct evaluation 203. The secondary storage medium (501-1, 501-2,501-3) is coupled to the interface IF_C (409-1, 409-2, 409-3) of eachmodule. A unit log derived from actual product evaluation is bufferedinto the RAM 402 and then stored in the secondary storage medium (501-1,501-2, 501-3) of each module. The secondary storage medium (501-1,501-2, 501-3) is used as a save destination when the size of the unitlog is larger than that of the RAM 402. If the unit log is smaller insize than the RAM 402, the unit log need not be saved into the secondarystorage medium (501-1, 501-2, 501-3).

FIG. 9 illustrates the procedure for actual product evaluation. Theactual product evaluation includes an application process S401 and atime synchronization process (S400, S405). The time synchronizationprocess is performed to synchronize the times of the synchronizationtimers of the modules (that is, synchronize the times counted by thetimers). For example, IEEE 1588 for Ethernet (registered trademark) is arelevant existing processing standard. As there is no existing standardfor non-Ethernet interfaces, it is assumed here that the timesynchronization process is performed on the basis, for instance, of thealgorithm of IEEE 1588.

The time synchronization process will now be described. The timesynchronization process is a process of transmitting time informationthrough an interface and synchronizing the value of the synchronizationtimer 404 at a receiving end with the value of the synchronization timer404 at a transmitting end. The time synchronization process mainlyincludes a communication delay measurement process and a clock errorcorrection process.

As an example of the time synchronization process, the timesynchronization process between the first module 500-1 and the secondmodule 500-2 is described below. It is assumed in the example that thefirst module 500-1 is at a transmitting end while the second module500-2 is at a receiving end, and that the process is performed tosynchronize the value of the synchronization timer 404-2 with the valueof the synchronization timer 404-1. Synchronization engine A 406 isimplemented in the interface IF_A 405 that couples the first module500-1 to the second module 500-2. Synchronization engine A 406 iscapable of acquiring the value of the synchronization timer 404 when atime synchronization command is transmitted or received. In theconfiguration depicted in FIG. 5, the first module 500-1 can acquire thetime of the synchronization timer 404-1 as synchronization commandtransmission/reception time, whereas the second module 500-2 can acquirethe time of the synchronization timer 404-2 as the synchronizationcommand transmission/reception time.

The communication delay measurement process (S400) will now bedescribed.

For example, let us assume a case where the time synchronization processis performed to transmit the time of the synchronization timer 404-1 inthe first module 500-1 and rewrite the time of the synchronization timer404-2 in the second module 500-2. If the timer value is simplyrewritten, the time of the synchronization timer 404-2 is delayed fromthe time of the synchronization timer 404-1 by a communication delaytime Tdelay. In the time synchronization process, therefore, thecommunication delay time Tdelay is measured and used as a correctionvalue for time synchronization at the receiving end.

FIG. 10 illustrates a procedure of measuring a communication delay inthe communication path 502. Let us assume that different values arerecorded in the synchronization timers 404-1, 404-2 in an initial state.The first module 500-1 first transmits a synchronization command (Sync).This causes the first module 500-1 to acquire a transmission time T1 andthe second module 500-2 to acquire a reception time T2. Next, the firstmodule 500-1 transmits a follow-up command (Followup) to notify thesecond module 500-2 of the transmission time T1. Upon receipt of thefollow-up command (Followup), the second module 500-2 issues a delayrequest command (DelayReq). This causes the second module 500-2 torecord a transmission time T3 and the first module 500-1 to record areception time T4.

Finally, the first module 500-1 issues a delay response command(DelayResp) to notify the second module 500-2 of the reception time T4.This causes the second module 500-2 to acquire the times T1, T2, T3, andT4.

The communication delay Tdelay in the communication path 502, that is,the time required for communication, can be determined by Equation 1below:

Tdelay=((T4−T1)−(T3−T2))/2  Equation 1

Here, it is assumed that the communication delay for transmission isequal to the communication delay for reception.

The difference (time difference) Tdiff between the synchronization timer404-1 and the synchronization timer 404-2 is determined by Equation 2below:

Tdiff=T2−(T1+Tdelay)  Equation 2

When the value Tdiff is subtracted from the time of the synchronizationtimer 404-2, the value of the synchronization timer 404-2 is equal tothe value of the synchronization timer 404-1. When the communicationdelay is to be measured for correction in the synchronization process,the count value of the synchronization timer 404-2 may be preset so thatthe value Tdiff is subtracted from the count value.

The clock error correction process will now be described.

FIG. 11 illustrates a communication sequence in the clock errorcorrection process. The clock error correction process is performed forthe purpose of correcting a clock frequency error, which may occurbecause the synchronization timers 404 use different clock oscillators.In an actual product system, it is preferred that the synchronizationtimers (404-1, 404-2, 404-3) use different clock oscillators in order toacquire an adequate degree of freedom of network configuration. In thisinstance, it is desirable that all the clock oscillators, which drivethe synchronization timers 404, oscillate at the same frequency. Inreality, however, the counts of the synchronization timers 404 deviatefrom each other during a continuous counting operation as eachoscillation frequency has an error. In other words, the result ofcorrection for synchronization based on communication delay measurementmay become erroneous over time. As such being the case, thesynchronization command (Sync) and the follow-up command (Followup) areperiodically transmitted during the clock error correction process tocorrect the synchronization timers 404. Referring to FIG. 11, a counterror Tcd is calculated from Equation 3 below when the first module500-1 transmits the synchronization command (Sync) at time T5 and thesecond module 500-2 receives the synchronization command (Sync) at timeT6:

Tcd=T6−(T5+Tdelay)  Equation 3

When Tcd is subtracted from the value of the synchronization timer 404-2of the second module 500-2, the value of the synchronization timer 404-2is equal to the value of the synchronization timer 404-1. The error iscorrected in this manner.

A synchronization interval (Sync Interval), which represents thefrequency at which the clock error correction process is performed,varies with implementation conditions. If the clock oscillators havehigh accuracy, the frequency may be low. However, if the clockoscillators have low accuracy, the clock error correction process needsto be frequently performed. In the present embodiment, it is assumedthat the synchronization interval (Sync Interval) is 1 second.

FIG. 12 illustrates the time synchronization process relationshipbetween the modules according to the present embodiment. In the presentembodiment, the synchronization timer 404-1 of the first module 500-1serves as the reference so that the synchronization timers 404 of thesecond and third modules 500-2, 500-3 are synchronized with thereference.

When the power is turned on, the first and second modules 500-1, 500-2perform the communication delay measurement process (step S400) betweenthe interfaces IF_B (407-1, 407-2). The second module 500-2 performs acommunication process depicted in FIG. 10 and acquires thetransmission/reception times T1, T2, T3, and T4 from synchronizationengine B 408. The CPU 401-2 calculates Tdelay and Tdiff from thetransmission/reception times. Upon completion of the communication delaymeasurement process, the CPU 401-2 of the second module 500-2 uses thevalue Tdiff to synchronize the time of the synchronization timer 404-2with the time of the synchronization timer 404-1.

Further, the synchronization timer 404-1 of the first module 500-1generates a periodic interrupt and requests the CPU 401-1 to perform theclock error correction process. Upon request, the CPU 401-1 performs acommunication process depicted in FIG. 11 to correct the clock error inthe second module 500-2. The second module 500-2 performs acommunication process depicted in FIG. 11 and acquires thetransmission/reception times T5 and T6 from synchronization engine B408. The CPU 401-2 calculates Tcd from the transmission/reception timesT5 and T6 and corrects the error in the synchronization timer 404-2.

The third module 500-3 performs the time synchronization process withrespect to the second module 500-2 in order to synchronize thesynchronization timer 404-3 with the synchronization timer 404-2. As thesecond module 500-2 is synchronized with the first module 500-1, thethird module 500-3 is also synchronized with the first module 500-1.

When the measurement sequence of the evaluation procedure depicted inFIG. 9 is initiated, the communication delay measurement process S400measures the communication delay and synchronizes the synchronizationtimers (404-1, 404-2, 404-3). Upon completion of synchronization, theapplication process S401 is performed. The clock error correctionprocess S405 is performed each time a clock error correction interrupt(S402) is generated for the clock error correction process. Processingsteps S401, S402, S403, and S405 are then repeated until the end ofevaluation is verified in step S403.

FIG. 20 illustrates the relationship between the application processS401 and clock error correction process S405 that are performed in thesecond module 500-2. In FIG. 20, shaded tasks (for example, S600-3)represent the application process S401, whereas white tasks (forexample, S600-2) represent the clock error correction process S405.

The second module 500-2 receives an error correction process signal(receives Sync/Followup) from the first module 500-1 and synchronizesthe synchronization timer 404-2 with the first module 500-1. Further,the second module 500-2 transmits the error correction process signal(transmits Sync/Followup) to the third module 500-3 and synchronizes thesynchronization timer 404-3 of the third module 500-3 with the secondmodule 500-2.

The CPU 401-2 of the second module 500-2 mainly performs the applicationprocess. The CPU 401-2 references the synchronization timer 404-2(S601-5, S602-3) at a test point and outputs a log. Upon receipt of theerror correction process signal (upon receipt of Sync/Followup) 601-2,the CPU 401-2 interrupts the application process, initiates the clockerror correction process, and corrects the synchronization timer 404-2.

The synchronization timer 404-2 generates an interrupt to interrupt theCPU 401-2 each time the synchronization interval (Sync Interval) iselapsed (S602-2). Upon receipt of the interrupt, the CPU 401-2 transmitsthe error correction process signal (transmits Sync/Followup) S601-4,S603-2 to the third module 500-3 and corrects the synchronization timer404-3 of the third module 500-3.

When the synchronization process is performed between the individualmodules, timestamps based on the same time axis can be added to the unitlogs in all the modules.

Returning to FIG. 9, when the evaluation of the actual product isterminated (S403), the unit logs accumulated in the secondary storagesof the modules are collected (S404). In the present embodiment, a loganalyzer 301 is coupled to the interface IF_A 405-1 of the first module500-1 in order to acquire the unit logs by communication. The unit logof the third module 500-3 is transmitted to the second module 500-2through the communication path 503. The unit log of the second module500-2 is transmitted to the first module 500-1 through the communicationpath 502. The unit log of the first module 500-1 is transmitted to thelog analyzer through a communication path 504.

The log analyzer 301 rearranges the contents of the unit log set 202obtained from the actual product system 201 and converts the unit logset 202 to a merged log 302. FIG. 14 illustrates a merging process.Timestamps are recorded on the unit logs (202-1, 202-2, 202-3) of theindividual modules. The log analyzer 301 rearranges data at each testpoint so that the data are aligned chronologically in accordance withthe timestamps.

Next, the log analyzer 301 references the tag table 105 of the mergedlog 302 and converts the tag information (the net ID, the tag number,and the tag value) into an arbitrary form. FIG. 15 illustrates theresult of table referencing.

Finally, the system specifications 101 and the system log 303 arecompared for software verification 307. FIG. 16 illustrates an examplein which software operations are visualized from the system log. Theexample in FIG. 16 indicates how a command is transmitted from the firstmodule 500-1 to the third module 500-3 and how a response is returnedfrom the third module 500-3 to the first module 500-1. As is obviousfrom FIG. 16, the operations of the software running in the modules 500can be verified while maintaining temporal consistency.

In the first embodiment, the system log 303 is used to visualizesoftware operations. However, the use of the system log 303 is notlimited to visualization. The system log 303 is also applicable toautomatic agreement verification of a model based on the systemspecifications 101, which is depicted, for instance, in FIGS. 6, 7, and8, and the system log 303, and to comparison between a simulation resultand the system log 303.

The first embodiment has been described on the assumption that threemodules are used. In reality, however, a larger number of modules aredaisy-chained. The daisy-chained modules are subjected to the timesynchronization process according to the first embodiment. Further, anynetwork (a later-described star-coupled network or mesh-coupled network)may be formed by the modules included in the system as far as the systemincludes at least three daisy-chained modules.

The first embodiment provides the following operational advantages.

(1) In the first embodiment, the synchronization timers 404 areintroduced so that all modules can gain access at a common time. When amethod described in Japanese Unexamined Patent Publication No.2012-190197 is used, the log of an event originated from a sub-CPUcannot be acquired because logs are merged with reference to time atwhich the sub-CPU is kicked by the main CPU. However, the firstembodiment uses the synchronization timers, which are clocks indicativeof a common time. Therefore, the first embodiment makes it possible toacquire the logs without being affected by the configuration of thesystem or of the network. The method described in Japanese UnexaminedPatent Publication No. 2012-190197 permits the use of a star networkonly because the relationship between the main CPU and sub-CPUs isessential. However, the first embodiment permits the use of a treenetwork and a mesh network.

(2) In the first embodiment, a timestamp can be added at the same timethe tag information is acquired. In the systems proposed in JapaneseUnexamined Patent Publications No. 2010-204934 and No. Hei 09(1997)-218800, timestamps are added by a debugging device coupledexternal to a module. Therefore, if logs are accumulated in the moduleor an interface with a significant delay is used for log output, timediscrepancy occurs with respect to event occurrence. In the firstembodiment, however, a timestamp indicative of the time of asynchronization timer in a module is added at the same time the taginformation is acquired. Therefore, no time discrepancy occurs even iflogs are accumulated in the module. Consequently, the following uses aremade possible:

(a) An interface with a significant delay can be used for logacquisition.(b) Even when the modules are dispersively installed at remote places,logs can be output and accumulated.(c) Logs can be internally accumulated while an application is runningand transferred to the outside after the application stops running.Therefore, the influence of log acquisition on the running of theapplication is minimized.(d) Logs can be accumulated in the modules. Therefore, software can beanalyzed as far as an inter-module interface can perform the timesynchronization process. The network requirements of the system, such asthe required speed of inter-module communication, can be relaxed.

(3) In the first embodiment, the synchronization timers are correctedduring the time synchronization process. The method described inJapanese Unexamined Patent Publication No. 2012-190197 does not performa time synchronization process. Therefore, if a sub-CPU operates for along period of time even in a situation where an event is originatedfrom the main CPU or if the main CPU and the sub-CPU communicate witheach other at high speed, logging time discrepancy occurs. Further, whenthe method described in Japanese Unexamined Patent Publication No.2012-190197 is used, state transitions and other high-speed softwareoperations cannot possibly be analyzed without performing the timesynchronization process.

In the first embodiment, time synchronization is accurately achieved byperforming the time synchronization process. Therefore, the firstembodiment is applicable to high-speed software operations and long-termmodule operations. Further, even when the modules use different clockoscillators, the modules can be synchronized by performing the timesynchronization process. Therefore, the first embodiment makes itpossible to analyze modules that are physically arranged apart from eachother.

(4) In the first embodiment, logs output dispersively from theindividual modules are merged by the log analyzer 301 to generate thesystem log. As the logs are analyzed by the log analyzer, the actualproduct system does not need to analyze or merge the logs. Consequently,analysis can be made without affecting the application process of theactual product system.

Second Embodiment

A second embodiment of the present invention additionally uses emulatorsor other verification devices for software analysis in order to enhancethe accuracy of verification. The second embodiment will be describedwith reference to a case where the method described in conjunction withthe first embodiment is applied to a system verification environment(system development environment). A verification procedure is depictedin FIG. 17. The verification procedure is performed to conduct an actualproduct evaluation 203-2 of an actual product verification system 201-2and conduct an expected-value agreement verification 611 and anoperation agreement verification 612.

The actual product verification system 201-2 is an actual productevaluation environment for verifying the operation of a target system605 defined by system specifications 101-2. The actual productverification system 201-2 includes the target system 605, emulator A604, and emulator B 606. The emulators emulate a device coupled to thetarget system 605. Although details are given later, it is assumed herethat the target system 605, emulator A 604, and emulator B 606correspond to the modules according to the first embodiment. It is alsoassumed that the target system 605, emulator A 604, and emulator B 606output a system log 303-2 as an operation log when software analysis ismade in accordance with the first embodiment.

The expected-value agreement verification 611 is a verification in whichthe output of the target system 605 is compared against an expectedvalue (subjected to black-box testing). In the expected-value agreementverification 611, a test scenario 603, which describes a verificationprocedure, is created from the system specifications 101-2, and an inputpattern 608 and an output expected value 607 are generated from the testscenario 603. The input pattern 608 is used for testing. The outputexpected value 607 represents an expected value that prevails when atest is normally ended. The input pattern 608 is used to conduct theactual product evaluation 203-2 of the actual product verificationsystem 201-2 and obtain an actual product output 609. The expected-valueagreement verification 611 is performed on the actual product output 609and the output expected value 607 to verify whether the target system605 is operating normally.

In the operation agreement verification 612, a system model 600 of thetarget system 605 is compared against the system log 303-2 to verify theinternal operation of the software (conduct white-box testing).

The system model 600 is data descriptive of software operations andformed of a target model 602 and an emulator model 601. The target model602 is descriptive of the operations of the target system 605. Theemulator model 601 is descriptive of the operations of an externallycoupled device.

The system log 303-2 records the operations of the target system 605,emulator A 604, and emulator B 606 as depicted in FIG. 17. The recordedinformation is compared against the system model 600 to verify whetherthe target system 605 agrees with the system specifications 101-2.

FIG. 18 illustrates a sequence in which emulator A 604 and emulator B606 issue command A to the target system 605. It is assumed in thisinstance that a first scenario S500-1 and a second scenario S500-2 areequal to each other in input/output and different only in the timing ofcommand issuance. In the first scenario S500-1, emulator A 604 issuescommand A (S501-1) earlier than emulator B 606. In the second scenarioS500-2, emulator B 606 issues command A (S502-2) earlier than emulator A604.

When the expected-value agreement verification 611 is performed in arelated-art manner, only the inputs/outputs of the first scenario S500-1and the second scenario S500-2 are compared. Therefore, the differencebetween the first scenario S500-1 and the second scenario S500-2, whichare equal in input/output and different in operation, cannot beverified. When the system log 303-2 is acquired and the relationshipbetween the operations of the target system 605, emulator A 604, andemulator B 606 is acquired, differently timed test scenarios can beevaluated.

The second embodiment provides the following operational advantages.

When a related-art method is used, only the expected-value agreementverification 611 can be performed. However, when the system log 303-2 ofthe target system 605, emulator A 604, and emulator B 606 is acquired inaccordance with the second embodiment, the operation agreementverification 612 can be performed. As described with reference to FIG.18, the operation agreement verification 612 makes it possible toconduct a timing-dependent event evaluation.

Third Embodiment

A third embodiment of the present invention will now be described withreference to a method of acquiring a unit log set 202-3 by using an SDcard or other portable storage medium. FIG. 19 illustrates theconfiguration of the third embodiment.

FIG. 19 illustrates a case where the third embodiment is applied to theevaluation of a robot arm 700. A first control module 702-1, a secondcontrol module 702-2, and a third control module 702-3, which providemotor control, are respectively incorporated into movable sections701-1, 701-2, 701-3 of the robot arm 700. The individual control modules702-1, 702-2, 702-3 are subjected to software analysis according to thefirst embodiment, and resulting unit logs are stored in a first SD card703-1, a second SD card 703-2, and a third SD card 703-3, respectively.After the evaluation of the robot arm 700 is ended, a developer removesthe SD cards 703-1, 703-2, 703-3 and reads data with a personal computeror the like to obtain the unit log set 202-3.

In the systems proposed in Japanese Unexamined Patent Publications No.2010-204934 and No. Hei 09 (1997)-218800, a test device needs to becoupled external to a module. Such a test device is readily applicableto a target that does not move during evaluation. However, such a testdevice cannot be readily applied to a robot, an automobile, or othertarget that moves during evaluation due, for instance, to aninstallation space and the influence of the test device on motion.

As described thus far, the timestamp is added at the same time the loginformation is acquired. Therefore, logs dispersively output from theindividual modules can be merged and accumulated. This feature makes itpossible to temporarily store the logs in an SD card or othersmall-size, portable storage medium. The use of a small-size storagemedium does not significantly affect the installation space or themotion of the robot arm. Therefore, the third embodiment is readilyapplicable to a situation where such limitations are imposed.

Further, as the storage medium can be removed and subsequently used toanalyze a unit log, the third embodiment remains unaffected by the speedof communication between the modules. Consequently, the third embodimentis effective even in a situation where the speed of inter-modulecommunication is low so that the communication for log collection takesan undue amount of time.

Fourth Embodiment

A fourth embodiment of the present invention will now be described. FIG.21 illustrates a case where the fourth embodiment is applied to a systemin which a large number of modules are coupled to a network within, forinstance, an automobile. The first embodiment has been described withreference to a case where a one-to-one daisy-chain coupling scheme isemployed. The fourth embodiment will be described with reference to acase where a network is formed. In the example depicted in FIG. 21, alarge number of ECUs (electronic control units), which control anautomobile 800, are network-coupled. The time synchronization process isperformed so that all modules are synchronized with a central controlECU 801. In this instance, the type of network is not limited to aone-to-one coupling type or a daily-chain coupling type. The fourthembodiment can be applied to any type of network, including a buscoupled network 802, a tree network 803, and a mesh network 804.

While the embodiments of the present invention have been described, thepresent invention is not limited to the specific embodiments describedabove. It is to be understood that many variations and modifications ofthe present invention may be made without departing from the spirit andscope of the present invention.

For example, it has been assumed that the unit source described withreference to FIG. 2 is obtained by combining an application functionwith time synchronization, tag management, and tag insertion functionsfor system verification, and operated as depicted in FIG. 20. However, asystem evaluation function based on the unit source set may be used notonly for the evaluation of the actual product system at a developmentstage, but also for failure detection. In such an instance, the timesynchronization, tag management, and tag insertion functions may bedisabled during an actual operation. For example, the timesynchronization, tag management, and tag insertion functions may beenabled only when an evaluation mode is selected for the system.

Further, the time synchronization process has been described withreference to a case where time settings of the synchronization timersare actually corrected. However, the time synchronization process is notlimited to such a case. For example, an alternative is to retain thesynchronization timer difference (time difference) Tdiff and count errorTcd, which are derived from communication delay measurement, as data,correct the synchronization timer time acquired at a tag point with thedifference (time difference) Tdiff and count error Tcd, and form thetimestamp by using the corrected time information.

Furthermore, the logs may be analyzed by using the CPU of one module.

Moreover, the functional configuration of a microcomputer or a dataprocessing device, which is used in the form of the SOC or the like, isnot limited to that depicted in FIG. 4, but may be changed asappropriate.

What is claimed is:
 1. A method of performing a cooperative dataprocessing, said method comprising performing a plurality of processesin each of a plurality of control modules capable of communicating witheach other to perform the cooperative data processing, the plurality ofprocesses comprising: a required application process of the cooperativedata processing; a unit log generation process during which, at a testpoint designated by a program executed in the unit log generationprocess, the unit log generation process generates timestamps inaccordance with log information and with time information derived fromthe timer and accumulates the timestamps together with attributeinformation about the test point to generate a unit log; and a timesynchronization process in accordance with a program executed by thecontrol modules, the time synchronization process being performed by thetimer for time synchronization specifically for the cooperative dataprocessing performed by the plurality of control modules, the timesynchronization process synchronizing an overall time for thecooperative data processing by synchronizing time information derivedfrom a timer in a low-level control module with time information derivedfrom a timer in a high-level control module, wherein the timesynchronization process comprises a process in which the low-levelcontrol module receives from the high-level control module informationabout the timer time of the high-level control module and corrects itslocal timer time in accordance with the received information about thetime and with the information about its local timer time and otherinformation prevailing when the information about the time is received.2. The method of claim 1, wherein the process of correcting the localtimer time comprises a process of rewriting the local timer time.
 3. Themethod of claim 1, wherein the process of correcting the local timertime comprises a process of correcting time information derived from thelocal timer at a time of timestamp generation.
 4. The method of claim 1,further comprising: acquiring a communication delay in a communicationfrom the high-level control module to the low-level control module;computing a timer time error by subtracting the communication delay fromthe difference between an actual transmission time and a reception time;and using the computed timer time error to correct the timer time. 5.The method of claim 1, further comprising, in external interfacecircuits: exercising control to acquire time information from the localtimer upon a receipt of a first command; outputting a second commandtogether with timer time information prevailing at a time of an outputof the first command; exercising control to acquire the local timer timeinformation at a time of an output of a third command; and outputting afourth command together with the local timer time information prevailingupon a receipt of the third command.
 6. The method of claim 5, whereinthe low-level control module: acquires first time information from thelocal timer upon receipt of the first command from the high-levelcontrol module; acquires second time information about a high-leveltimer that prevails when the high-level control module outputs the firstcommand together with the second command; acquires third timeinformation about the local timer when the third command is output tothe high-level control module; acquires fourth time information aboutthe high-level timer that prevails upon receipt of the third command,the third command being output together with the fourth command by thehigh-level control module upon receipt of the third command; computestime that is half of a sum of a difference between the fourth timeinformation and the first time information and a difference between thethird time information and the second time information; acquires thecomputed time as the communication delay in the communication from thehigh-level control module to the low-level control module; computes thetimer time error by subtracting the communication delay from thedifference between the actual transmission time and reception time; andcorrects the timer time by using the computed timer time error.
 7. Themethod of claim 6, wherein the external interface circuits each includesa synchronization control circuit that: acquires first time informationfrom the local timer upon receipt of the first command; acquires secondtime information supplied together with the second command; acquiresthird time information about the local timer when the third command isoutput; and acquires fourth time information supplied together with thefourth command.
 8. The method of claim 7, wherein the central processingunit computes the communication delay and the time error by using thefirst to fourth time information acquired by the external interfacecircuits.
 9. The method of claim 8, wherein the central processing unitmeasures the communication delay before the start of an applicationprocess and controls a process of initially correcting the timer time byusing the measured communication delay.
 10. The method of claim 9,wherein, after the initial timer time correction, the central processingunit controls a process of correcting timer time with the measuredcommunication delay in accordance with a timer interrupt generated atpredetermined intervals.
 11. The method of claim 1, wherein theattribute information about the test point includes first identificationinformation allocated to a control module, second identificationinformation indicative of the location of the test point within aprogram executed by the control module, and third identificationinformation indicative of a process performed at the test point.
 12. Themethod of claim 1, further comprising: collecting, in a log analysiscircuit, unit logs generated for the control modules; consolidating theunit logs by merging test point attribute information, log information,and timestamps by using timestamps included in the collected unit logsas an index; and generating a system log.
 13. The method of claim 1,wherein the control modules are configured as in-vehicle ECUs coupled toan in-vehicle network.
 14. The method of claim 1, wherein the controlmodules are configured as an actual product, which is to be emulated, oras emulators, which emulate the actual product.
 15. A method ofperforming a cooperative data processing, said method comprising:performing a cooperative data processing in a plurality of controlmodules that operate while communicating with each other as a dataprocessing system, the control modules each including a timer thatcounts a time common to the entire data processing system implementingthe cooperative data processing; and performing a time synchronizationprocess for the cooperative data processing between the control modulesso that time information derived from a timer in a low-level controlmodule is synchronized with time information derived from a timer in ahigh-level control module.
 16. The method of claim 15, wherein thecontrol modules further perform a log acquisition process during anapplication process to acquire a log and to add a timestamp based ontimer time to the acquired log.
 17. The method of claim 16, furthercomprising: collecting logs acquired by a log acquisition function ofthe individual control modules; merging information about the collectedlogs in accordance with timestamps; and generating a system log ofsoftware running in the entire data processing system.
 18. A method ofperforming a cooperative data processing in a plurality of controlmodules capable of communicating with each other, the control moduleseach including communication interfaces and a timer, and each performinga required application process, a unit log generation process, and atime synchronization process in accordance with a program executed bythe control modules, the time synchronization process being performed bythe timer for time synchronization purposes, said method comprising: ata test point designated by a program executed in the unit log generationprocess, the unit log generation process generates timestamps inaccordance with log information and with time information derived fromthe timer, and accumulates the timestamps together with attributeinformation about the test point to generate a unit log; in the timesynchronization process, synchronizing the time information derived fromthe timer in a low-level control module with the time informationderived from the timer in high-level control module; and in an externalinterface circuit of a first control module, acquiring time informationfrom its local timer upon receipt of a first command from a secondcontrol module, receiving from the second control module a secondcommand together with timer time information of the second controlmodule prevailing at a time that the second control module output thefirst command, acquiring its local timer time information at a time ofoutputting of a third command to the second control module, andreceiving a fourth command from the second control module together withtimer time information of the second control module prevailing at a timethe second control module received the third command.
 19. The method ofclaim 18, wherein the first control module comprises a low-level controlmodule and the second control module comprises a high-level controlmodule, such that the low-level control module: acquires first timeinformation from its local timer upon a receipt of the first commandfrom the high-level control module; acquires second time informationabout the high-level timer that prevailed when the high-level controlmodule outputted the first command together with the second command;acquires third time information from its local timer when the thirdcommand is outputted to the high-level control module; acquires fourthtime information about the high-level timer that prevailed upon areceipt of the third command, the fourth time information being outputtogether with the fourth command by the high-level control module upon areceipt of the third command; computes time that is half a sum of adifference between the fourth time information and the first timeinformation and a difference between the third time information and thesecond time information; acquires the computed time as a communicationdelay in a communication from the high-level control module to thelow-level control module; computes a timer time error by subtracting thecommunication delay from a difference between an actual transmissiontime and a reception time; and corrects the timer time by using thecomputed timer time error.
 20. A method of performing a cooperative dataprocessing, said method comprising coupling a plurality of controlmodules in series, each said control module having a first communicationinterface and a second communication interface, the control modulesbeing coupled such that the second communication interface of apreceding one of the control modules is connected to the firstcommunication interface of a succeeding one of the control modules, eachof the control modules comprising: a timer, and a central processingunit (CPU), wherein the CPU executes a required application process, aunit log generation process, and a time synchronization process inaccordance with a program executed by the control module, the timesynchronization process being performed by the timer for timesynchronization purposes, wherein, at a test point designated by aprogram executed in the unit log generation process, the unit loggeneration process generates timestamps in accordance with loginformation and with time information derived from the timer, andaccumulates the timestamps together with attribute information about thetest point to generate a unit log, wherein the time synchronizationprocess receives a first time information when the preceding one of thecontrol modules transmits a first command, acquires a second timeinformation from the timer when the first command is received throughthe first communication interface, and synchronizes the second timeinformation with the first time information.